7장. 파인튜닝

출처 — Chip Huyen, 『AI 엔지니어링』(한국어판), 7장 (pp. 364~425). 원문 PDF ai_engineering_final_v11_260909.pdf (2026-09-09 판)

파인튜닝은 모델의 가중치를 직접 조정해 특정 작업에 맞게 바꾸는 과정이다. 언제 파인튜닝이 필요하고 언제 RAG로 충분한지를 오류의 원인으로 가르는 기준부터, 메모리 병목의 정체, 파라미터 효율적 파인튜닝(PEFT)과 LoRA의 작동 원리, 여러 모델을 하나로 합치는 모델 병합까지 다룬다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 파인튜닝을 전이 학습의 한 갈래로 설명하고, 지속적 사전 학습·지도 파인튜닝·선호도 파인튜닝·롱 컨텍스트 파인튜닝을 구분한다.
• 모델 오류의 원인이 정보 부족인지 행동 방식 문제인지를 근거로 RAG와 파인튜닝 중 무엇을 선택할지 판단한다.
• 모델의 추론·학습 메모리 사용량을 N×M 공식과 옵티마이저 스테이트 개수로 직접 계산한다.
• 전체 파인튜닝과 파라미터 효율적 파인튜닝(PEFT)의 차이를 설명하고, LoRA의 구성 요소(랭크·타깃 행렬·병합/분리 서빙)를 구현 수준에서 설명한다.
• 모델 병합의 세 접근(합산·레이어 쌓기·연결)을 구분하고, 다중 작업 파인튜닝이나 온디바이스 배포 상황에 적용할 방법을 고른다.

전체 흐름도

[ 파인튜닝이란 ]
   전이 학습의 한 갈래 — 사전 학습된 기본 모델의 가중치를 추가로 조정
   유형: 지속적 사전 학습 · 지도 파인튜닝 · 선호도 파인튜닝 · 롱 컨텍스트 파인튜닝
      │
      ▼
[ 먼저 물어야 할 질문 — 정말 파인튜닝이 필요한가? ]
   해야 하는 이유 — 특정 작업 성능·구조화된 출력·편향 완화·작은 모델 특화
   하지 말아야 하는 이유 — 다른 작업 성능 저하·초기 투자(데이터·ML지식·서빙)·프롬프팅으로 충분할 수도
      │
      ▼
[ 파인튜닝 대 RAG — 오류 원인으로 가른다 ]
   정보 부족 오류 ──────→ RAG         행동 방식 문제 ──────→ 파인튜닝
   "파인튜닝은 형식을 위한 것, RAG는 사실을 위한 것" · 함께 쓸 수도 있다(상호 배타 아님)
      │  (파인튜닝을 하기로 결정했다면)
      ▼
[ 메모리 병목 현상 ]
   학습 메모리 = 가중치 + 활성화 + 그래디언트 + 옵티마이저 스테이트
   학습 가능한 파라미터 수 ↓ → 메모리 ↓        수치 정밀도 ↓(양자화) → 메모리 ↓
      │
      ▼
[ 파라미터 효율적 파인튜닝(PEFT)과 LoRA ]
   전체 파인튜닝 → 부분 파인튜닝 → PEFT(어댑터 기반 · 소프트 프롬프트 기반)
   LoRA: W' = W + B·A, A·B만 학습 → 서빙 방식 2가지 → QLoRA(양자화 결합)
   + 모델 병합(합산·레이어 쌓기·연결) + 실전 하이퍼파라미터(학습률·배치·에폭)
      │
      ▼
[ 8장: 파인튜닝에 넣을 고품질 지시 데이터를 어떻게 확보하고 만드는가 ]

0. 용어 사전

참고 — 위쪽 4개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 2장을 먼저 보면 좋다. 나머지는 이 장에서 처음 정의하는 개념이다.

1. 파인튜닝이란 무엇인가

파인튜닝은 모델 전체나 일부를 추가로 학습시켜 특정 작업에 맞게 조정하는 과정이다. 5장과 6장에서 다룬 프롬프트 기반 방법이 모델에 지시·컨텍스트·도구를 "보여주는" 방식으로 모델을 조정한다면, 파인튜닝은 모델의 가중치 자체를 바꿔 모델을 변화시킨다. 목적은 코딩·의료 질의응답 같은 도메인별 능력 향상, 안전성 강화일 수도 있지만, 실무에서 가장 흔한 목적은 모델의 지시 수행 능력을 끌어올려 특정 출력 스타일·형식을 지키게 만드는 것이다.

파인튜닝은 전이 학습(1976년 보지노프스키와 풀고시가 처음 제안한 개념)의 한 방법이다. 전이 학습은 한 작업에서 얻은 지식을 관련된 새 작업에 활용해 학습 속도를 높이는 데 중점을 둔다. 초기 대규모 성공 사례는 구글의 다국어 번역 시스템(Johnson et al., 2016)으로, 포르투갈어-영어와 영어-스페인어 번역 지식을 전이해 학습 데이터에 없던 포르투갈어-스페인어 번역까지 해냈다. LLM에서는 텍스트 완성(데이터가 풍부한 작업)에서 얻은 사전 학습 지식이 법률 질의응답이나 Text-to-SQL 같은 더 전문적이고 데이터가 적은 작업으로 전이된다. 전이 학습은 표본 효율성도 높인다 — 법률 질의응답 모델을 처음부터 학습하려면 수백만 개의 예시가 필요할 수 있지만, 좋은 기본 모델을 파인튜닝하면 단 몇백 개만으로도 충분할 수 있다.

참고 — 파인튜닝이 전이 학습의 유일한 방법은 아니다. 특성 기반 전이(feature-based transfer)는 모델이 추출한 특성(주로 임베딩 벡터)을 다른 모델이 활용하는 방식으로, 2010년대 후반 컴퓨터 비전 분야에서 이미지넷으로 학습한 모델의 특성을 객체 탐지·이미지 분할에 재사용하던 것이 대표적이다.

모델 학습은 보통 자기 지도 학습 방식의 사전 학습에서 시작한다. 자기 지도 학습은 레이블이 필요 없는 대량의 텍스트에서 학습하는 방식이다. 비싼 (질의, 응답) 주석 데이터로 파인튜닝하기 전에, 저렴한 관련 분야 텍스트로 먼저 자기 지도 학습을 이어갈 수 있는데, 이를 지속적 사전 학습이라고 부른다. 예를 들어 법률 질의응답 모델을 만들 때는 비싼 (질의, 응답) 주석 데이터로 파인튜닝하기 전에, 값싼 법률 문서 원문으로 먼저 지속적 사전 학습을 적용해 볼 수 있다.

1장에서 설명했듯이 언어 모델은 자기회귀 언어 모델과 마스크 언어 모델로 나뉜다. 자기회귀 모델은 이전 토큰을 컨텍스트로 다음 토큰을 예측하고, 마스크 모델은 앞뒤 토큰을 모두 활용해 빈칸을 채운다. 지도 파인튜닝도 마찬가지로 다음 토큰을 예측하게 하거나 빈칸을 채우게 할 수 있다. 후자는 인필링 파인튜닝이라 부르며, 텍스트 편집이나 코드 디버깅처럼 문서 중간을 고쳐야 하는 작업에 특히 유용하다. 흥미롭게도 자기회귀 방식으로 사전 학습된 모델이라도, 학습 데이터의 형식을 "시작-중간-끝" 같은 특정 틀로 바꿔주면 인필링 파인튜닝이 가능하다 — 모델에게는 여전히 "다음에 올 내용 맞히기" 문제이기 때문이다.

지도 파인튜닝은 (입력, 출력) 쌍으로 모델을 학습시킨다. 입력은 지시, 출력은 응답이며, 응답은 책 요약처럼 개방형일 수도 분류 작업처럼 폐쇄형일 수도 있다. 고품질 지시 데이터를 만드는 일은 사실적 일관성·도메인 전문 지식·정치적 정확성이 필요할 때 특히 생성하기 어렵고 비용이 많이 든다(지시 데이터를 확보하는 구체적 방법은 8장 §5에서 다룬다). 선호도 파인튜닝은 강화 학습을 통해 사람의 선호도를 최대화하는 응답을 만들도록 조정하며, 보통 (지시, 선호 응답, 비선호 응답) 형식의 비교 데이터가 필요하다.

롱 컨텍스트 파인튜닝은 모델의 컨텍스트 길이를 늘리기 위한 파인튜닝으로, 보통 위치 임베딩 조정 같은 모델 구조 수정이 필요하다. 롱 시퀀스는 토큰이 놓일 수 있는 위치가 더 많아지므로 위치 임베딩이 이를 처리할 수 있어야 한다. 다른 파인튜닝보다 까다롭고, 결과 모델이 오히려 짧은 시퀀스에서는 성능이 떨어질 수도 있다. 예를 들어 코드 라마 모델은 기본 모델 라마 2에 롱 컨텍스트 파인튜닝을 적용해 최대 컨텍스트 길이를 4,096 토큰에서 16,384 토큰으로 늘려 더 긴 코드 파일을 다룰 수 있게 했다(Rozière et al., 2024).

파인튜닝은 모델 개발자와 애플리케이션 개발자 모두가 수행할 수 있다. 모델 개발자는 주로 모델을 출시하기 전에 다양한 기법으로 사후 학습을 시키고, 파인튜닝 정도가 다른 여러 버전을 내놓아 애플리케이션 개발자가 고를 수 있게 한다. 애플리케이션 개발자는 사전 학습된 원본 모델을 직접 파인튜닝할 수도 있지만, 대개는 이미 사후 학습을 거친 모델을 다시 파인튜닝하게 된다. 모델이 이미 정교하고 작업 관련 지식이 풍부할수록, 애플리케이션 개발자가 들여야 하는 조정 노력은 줄어든다.

2. 파인튜닝을 해야 하는 이유와 하지 말아야 하는 이유

여러 파인튜닝 기법을 살펴보기 전에, 파인튜닝이 정말 적합한 선택인지부터 따져 봐야 한다. 프롬프트 기반 방법과 비교하면 파인튜닝은 많은 데이터, 고사양 하드웨어, ML 전문 인력을 추가로 요구한다. 그래서 보통 프롬프트 기반 방법을 충분히 시도한 뒤에 파인튜닝을 시도하는 것이 일반적이지만, 둘은 양자택일 관계가 아니라 함께 쓰는 경우가 많다.

해야 하는 이유. 파인튜닝의 주요 목적은 일반 능력과 특정 작업 수행 능력을 함께 끌어올리는 것이다. JSON·YAML 같은 특정 구조의 출력을 생성할 때 특히 효과적이다. 범용 모델이 해당 작업에 충분히 학습되지 않았다면, 관련 자체 데이터로 파인튜닝하는 것이 효과적이다. 예를 들어 기본 모델이 표준 SQL 문법에는 강해도 덜 흔한 SQL 문법에서 실패한다면, 그 문법이 담긴 데이터로 파인튜닝하면 도움이 된다.

흥미로운 활용 사례는 편향 완화다. 기본 모델이 학습 데이터의 편향을 반영한다면, 신중하게 선별한 데이터로 파인튜닝해 이를 상쇄할 수 있다(Wang and Russakovsky, 2023). 가리멜라 등의 연구(2022)는 BERT 계열 언어 모델을 여성 작가의 텍스트로 파인튜닝하면 성별 편향이, 아프리카 작가들의 텍스트로 파인튜닝하면 인종적 편향이 줄어든다는 것을 보였다.

큰 모델을 파인튜닝해 더 개선할 수도 있지만, 실무에서는 작은 모델을 파인튜닝하는 경우가 훨씬 흔하다. 메모리 요구량이 적어 파인튜닝이 쉽고, 운영 환경에서도 더 저렴하고 빠르기 때문이다. 큰 모델이 생성한 데이터로 작은 모델을 학습시켜 큰 모델처럼 작동하게 만드는 방식을 증류라고 부르며, 8장 §5에서 다른 데이터 합성 기법과 함께 다시 다룬다. 특정 작업에 파인튜닝된 작은 모델이 같은 작업에서 훨씬 큰 기본 모델보다 뛰어날 수도 있다 — 그래머리는 파인튜닝된 Flan-T5 모델(Chung et al., 2022)이 텍스트 편집에 특화된 GPT-3 변형보다 다양한 글쓰기 보조 작업에서 더 좋은 성능을 보였다고 밝혔는데, 이 파인튜닝에는 단 82,000개의 (지시, 출력) 쌍만 쓰였다(텍스트 편집 모델을 처음부터 학습시키는 데 필요한 양의 60분의 1 수준).

콜아웃 — 도메인 특화 작업 파인튜닝을 조심하자. 범용 모델의 모든 능력이 강력해질수록 특정 도메인 작업에도 더 능숙해져, 도메인 특화 모델보다 오히려 나은 성능을 보일 수 있다. 2023년 3월 블룸버그가 공개한 블룸버그GPT(500억 파라미터, 학습에 A100 GPU 130만 시간, 컴퓨팅 비용만 약 130만~260만 달러 추정, Wu et al., 2023)가 대표 사례다. 같은 달 오픈AI가 GPT-4-0314를 출시했는데, 리 등의 연구(2023)에 따르면 GPT-4-0314가 다양한 금융 벤치마크에서 블룸버그GPT를 크게 앞섰다.

원문의 [표 7-1]을 재구성하면 다음과 같다(제로샷 기준).

물론 벤치마크만으로 실제 성능을 완전히 파악하긴 어려우므로 블룸버그GPT가 블룸버그의 특정 활용 사례에는 잘 맞을 수 있고, 블룸버그 팀은 이 모델을 학습시키며 이후 더 나은 모델을 만들 값진 경험을 쌓았을 것이다. 그 이후로 GPT-4에 버금가는 중간 규모 모델(클로드 3.5 소넷, 라마 3-70B-Instruct, Qwen2-72B-Instruct 등)이 여럿 출시됐고, 뒤의 두 모델은 오픈 웨이트라 누구나 자체 호스팅할 수 있다.

하지 말아야 하는 이유. 첫째, 특정 작업을 위해 모델을 파인튜닝하면 그 작업 성능은 오르지만 다른 작업에서는 성능이 떨어질 수 있다(일부에서는 이를 정렬 세금이라 부르지만, AI를 사람의 선호에 정렬할 때 생기는 성능 저하와 혼동하기 쉬운 용어다). 제품 추천·주문 변경·일반 피드백 세 유형의 질의를 처리해야 하는데 주문 변경 데이터로만 파인튜닝하면, 주문 변경 성능은 오르지만 나머지 두 작업 성능이 떨어질 수 있다. 이럴 때는 모든 필요한 작업을 함께 파인튜닝하거나, 작업별로 별도 모델을 두고 모델 병합(이 장 §5)으로 하나로 합치는 방법을 고려할 수 있다.

둘째, 초기 투자가 크다. 주석 데이터는 수동으로 모으기에 시간과 비용이 많이 들고(오픈 소스·AI 생성 데이터로 줄일 수는 있지만 효과는 경우마다 다르다), 파인튜닝은 옵티마이저·학습률·과적합/과소적합 대응·평가 방법 같은 모델 학습 지식을 요구하며, 파인튜닝된 모델을 어떻게 서빙할지(9장에서 다루는 추론 최적화)까지 결정해야 한다.

셋째, 지속적인 관리 비용이다. 새로운 기본 모델이 빠르게 나오는 상황에서, 공들여 파인튜닝한 모델을 계속 개선하는 속도가 새 기본 모델의 발전 속도를 못 따라갈 수 있다. 실제로는 더 좋은 모델로 바꿔도 성능 향상이 미미한 경우가 많아, 더 큰 수익이 기대되는 다른 프로젝트에 우선순위가 밀리곤 한다. 저자는 "프롬프팅이 효과 없다"고 불평하는 실무자를 자세히 조사해 보면 대개 프롬프트 실험이 최소한으로만, 체계적이지 않게 진행됐다는 사실을 발견했다고 지적한다 — 지시가 불명확하고, 예시가 실제 데이터를 반영하지 못하고, 평가 지표가 제대로 정의되지 않은 경우다. 5장에서 다룬 모범 사례로 프롬프트 실험을 개선하면 많은 애플리케이션이 요구하는 수준을 충분히 만족시킬 수 있다.

마지막으로, 프롬프트 캐싱(9장)이 도입되기 전에는 파인튜닝이 반복되는 예시를 프롬프트에 매번 넣지 않아도 되게 해 토큰 비용을 줄여주는 장점이 있었다. 지금은 이 장점이 줄었지만, 프롬프트와 함께 쓸 수 있는 예시 수가 최대 컨텍스트 길이에 제한되는 프롬프팅과 달리, 파인튜닝은 활용할 수 있는 예시 수에 제한이 없다는 차이는 여전히 남는다.

3. 파인튜닝 대 RAG — 오류 원인으로 판단한다

프롬프팅으로 성능을 최대한 끌어올렸다면, 다음은 RAG를 적용할지 파인튜닝을 할지 고르는 문제다. 이 선택은 모델 오류의 원인이 정보 부족인지 행동 방식의 문제인지에 달려 있다.

정보 부족 오류 → RAG. 모델이 정보가 부족해 오답을 내는 두 가지 상황이 있다. ① 모델이 애초에 그 정보를 가지고 있지 않은 경우 — 공개 모델은 사용자나 조직의 비공개 정보를 모르는 경우가 많다. ② 모델의 정보가 오래된 경우 — "테일러 스위프트는 정규 앨범을 몇 개 발매했나요?"에 정답이 11개인데 모델이 10개라고 답한다면, 모델의 지식 기준일이 최신 앨범 발매 이전이기 때문일 수 있다. 관련 정보 소스에 접근하게 해주는 RAG가 이런 경우에 효과적이다. 〈Fine-Tuning or Retrieval?〉(Ovadia et al., 2024)은 시사 문제·최신 정보가 필요한 작업에서 RAG가 파인튜닝된 모델보다 낫다는 점을 보였고, 더 흥미롭게도 기본 모델 + RAG가 파인튜닝된 모델보다도 더 나은 결과를 냈다.

원문 [표 7-2]는 추출 과정에서 표의 행과 열이 뒤섞여, 아래 두 줄(기본 모델과 기본 모델+RAG)만 확실히 복원할 수 있었다. 나머지 파인튜닝 조합(FT-reg·FT-par) 수치는 원문에서 값이 어느 모델·어느 조건에 속하는지 다시 판별할 수 없을 만큼 손상돼 옮기지 않는다.

기본 모델에 RAG만 얹어도 세 모델 모두 점수가 크게 오른 것을 볼 수 있다. 같은 연구에서 오바디아 등(2024)은 파인튜닝된 모델에 RAG를 추가하면 MMLU 벤치마크의 43% 시나리오에서 성능이 향상됐지만, 나머지 57%에서는 RAG 단독 사용과 비교해 어떤 개선도 없었다고 보고했다 — 파인튜닝과 RAG가 상호 배타적이지 않되, 함께 쓴다고 항상 이득이 보장되지는 않는다는 뜻이다.

행동 방식 문제 → 파인튜닝. 모델의 출력이 사실 관계는 맞지만 요청과 무관하거나(예: 정확하지만 팀이 실제로 필요로 하는 세부 사항이 빠진 기술 명세서), 원하는 형식을 못 따르는 경우(예: 학습 과정에서 HTML에 충분히 노출되지 않아 작동하지 않는 HTML 코드를 생성)가 행동 방식 문제다. 시맨틱 파싱(자연어를 JSON 같은 구조화된 형식으로 바꾸는 작업, 2장·6장에서 간략히 다룸)은 정해진 형식을 지키는 능력이 성패를 좌우하므로 파인튜닝이 자주 필요하다. 강력한 기성 모델은 JSON·YAML·정규 표현식처럼 흔한 구문에는 강하지만, 인터넷에서 예시를 찾기 어려운 구문(덜 유명한 도구의 특수 언어 등)에는 약할 수 있다.

요약하면 파인튜닝은 형식을 위한 것이고, RAG는 사실을 위한 것이다. RAG는 외부 지식을 제공해 더 정확한 응답을 만들고 환각을 줄이는 데 도움이 되며, 파인튜닝은 특정 문구·스타일을 이해하고 따르는 데 도움을 준다(충분한 고품질 데이터로 진행하면 환각을 줄일 수도 있지만, 데이터 품질이 낮으면 오히려 악화시킬 수 있다). 모델이 정보와 행동 양쪽 모두에 문제가 있다면 RAG부터 시작하는 것이 좋다 — 학습 데이터 수집이나 파인튜닝된 모델의 별도 운영이 필요 없어 더 쉽게 접근할 수 있고, 복잡한 벡터 데이터베이스보다 BM25 같은 단순한 키워드 검색부터 시작하는 편이 낫다.

단계별 판단 절차(원문의 개발 흐름을 재구성). 모델을 특정 작업에 맞게 조정하기 전에, 4장에서 설명한 평가 기준과 평가 파이프라인부터 설계해 둬야 한다(이 파이프라인은 전체 과정에서 진행 상황을 재는 기준점이 된다).

이 흐름에서 "잘못된 접근"은 2단계(예시 추가)를 건너뛰고 곧장 파인튜닝으로 가거나, 정보 부족 오류인데도 파인튜닝만으로 해결하려는 것이다. 정보 부족은 아무리 파인튜닝해도 모델이 애초에 갖지 못한 지식을 만들어내지 못하고, 오히려 그럴듯하게 지어내는 환각만 강화할 위험이 있다. "올바른 접근"은 표의 단계를 순서대로 밟으며, 매 단계 4장의 평가 파이프라인으로 실제 개선을 확인하는 것이다.

4. 메모리 병목 현상

파인튜닝은 메모리를 많이 쓰기 때문에, 많은 파인튜닝 기법이 메모리 사용량을 최소화하는 데 초점을 맞춘다. 이 절은 그 병목의 원인을 이해하고, 모델을 서빙·파인튜닝하는 데 필요한 하드웨어를 대략 가늠하는 계산식을 다룬다. ML 내부 동작과 시스템 수준 개념이 섞여 다소 어려울 수 있는 절이다.

참고 — 핵심만 먼저 — ① 파운데이션 모델의 큰 규모 때문에 추론과 파인튜닝 모두에서 메모리가 병목이 되며, 파인튜닝에 필요한 메모리는 보통 추론보다 훨씬 크다. ② 메모리 사용량을 크게 좌우하는 요소는 전체 파라미터 수·학습 가능한 파라미터 수·수치 표현 방식이다. ③ 학습 가능한 파라미터를 줄이면 메모리가 줄어든다 — 이것이 PEFT의 핵심 아이디어다. ④ 양자화(비트 수를 줄이는 것)는 메모리를 줄이는 간단하고 효과적인 방법이다. ⑤ 추론은 보통 16비트 이하로, ⑥ 학습은 정밀도에 더 민감해 주로 혼합 정밀도로 수행한다.

4.1 역전파와 메모리 계산

파인튜닝 중 메모리 사용량을 결정하는 핵심 요소는 학습 가능한 파라미터의 수다. 사전 학습에서는 모든 파라미터가 업데이트되지만, 추론에서는 어떤 파라미터도 업데이트되지 않는다. 파인튜닝 중에는 일부 또는 전체 파라미터가 업데이트될 수 있고, 업데이트되지 않는 파라미터를 고정된 파라미터라고 부른다.

신경망은 주로 역전파로 학습된다. 각 학습 단계는 두 패스로 구성된다. ① 순방향 패스 — 입력에서 출력을 계산한다(추론은 이 패스만 실행한다). ② 역방향 패스 — 순방향 패스의 출력과 정답을 비교해 손실을 구하고, 각 학습 가능한 파라미터가 그 손실에 얼마나 기여했는지(그래디언트)를 계산한 뒤, 옵티마이저가 그래디언트를 바탕으로 파라미터를 조정한다. 트랜스포머 기반 모델에서 가장 널리 쓰이는 옵티마이저는 Adam이다. 역방향 패스 동안 각 학습 가능한 파라미터는 그래디언트값 하나와, 옵티마이저에 따라 0~2개의 옵티마이저 스테이트를 함께 가진다.

• 기본 SGD 옵티마이저 — 스테이트 없음(파라미터당 그래디언트 1개)
• 모멘텀 옵티마이저 — 스테이트 1개(그래디언트 1개 + 스테이트 1개 = 2개)
• Adam 옵티마이저 — 스테이트 2개(그래디언트 1개 + 스테이트 2개 = 3개)

메모리 계산 공식. N을 파라미터 수, M을 파라미터 하나에 필요한 메모리라고 하면, 추론에 필요한 모델 가중치 메모리는 N × M이다. 여기에 어텐션의 활성화·키/값 벡터를 위한 메모리가 더해지는데, 많은 애플리케이션에서 이 값은 가중치 메모리의 약 20%로 가정할 수 있어(더 긴 컨텍스트·큰 배치를 쓰면 더 커진다), 추론 메모리는 대략 N × M × 1.2가 된다. 130억 파라미터 모델을 파라미터당 2바이트로 표현하면 가중치는 26GB, 추론 총 메모리는 26GB × 1.2 = 31.2GB가 된다. 파라미터당 2바이트를 쓰는 700억 파라미터 모델은 가중치만으로 140GB가 필요하다.

학습 메모리는 다음과 같이 구성된다.

학습 메모리 = 모델 가중치 + 활성화 + 그래디언트 + 옵티마이저 스테이트

그래디언트·옵티마이저 스테이트에 필요한 메모리는 학습 가능한 파라미터 수에 비례한다. Adam으로 130억 파라미터 전체를 파인튜닝한다면, 학습 가능한 파라미터마다 그래디언트 1개 + 옵티마이저 스테이트 2개, 총 3개의 값이 필요하다. 각 값을 2바이트로 두면 130억 × 3 × 2바이트 = 78GB다. 학습 가능한 파라미터가 10억 개뿐이라면 10억 × 3 × 2바이트 = 6GB로 크게 줄어든다 — 학습 가능한 파라미터를 줄이면 이 항이 그만큼 작아진다는 것이 PEFT의 출발점이다.

잘못된 계산 / 올바른 계산 — 70억 파라미터 모델을 FP16(파라미터당 2바이트)으로 Adam 전체 파인튜닝한다고 하자. 잘못된 계산은 가중치 메모리(14GB)만 보고 "14GB GPU면 충분하다"고 판단하는 것이다. 올바른 계산은 가중치 14GB에 그래디언트·옵티마이저 스테이트(70억 × 3 × 2바이트 = 42GB)를 더해 56GB로 잡아야 한다 — 이미 대부분의 소비자용 GPU(12~24GB, 고급형도 최대 48GB) 용량을 넘어서고, 여기에 활성화 메모리는 아직 포함하지도 않았다. 이 차이를 놓치면 "GPU 메모리가 부족하다"는 오류를 실제로 겪고 나서야 계산을 다시 하게 된다.

다만 이 공식은 활성화 메모리가 모델 가중치 메모리보다 작다고 가정한 것이다. 실제로는 그래디언트 계산을 위해 활성화를 저장해 둘 경우 활성화 메모리가 가중치 메모리를 크게 웃돌 수 있다(Korthikanti et al., 2022). 활성화를 저장하지 않고 필요할 때마다 다시 계산하는 방법을 그래디언트 체크포인팅(활성화 재계산)이라고 하며, 메모리 요구량은 줄지만 재계산 때문에 학습 시간이 늘어난다.

4.2 수치 표현 방식과 양자화

값을 표현하는 데 필요한 비트 수가 적을수록 메모리 사용량도 줄어든다. 신경망의 수치는 전통적으로 부동소수점으로 표현된다. FP32(32비트, 단정밀도)·FP16(16비트, 반정밀도)이 가장 흔하고, 구글이 TPU용으로 설계한 BF16과 엔비디아가 GPU용으로 설계한 TF32도 AI 워크로드에서 자주 쓰인다. 정수 형식(INT8·INT4)도 점점 인기를 얻고 있다.

각 형식은 부호 비트 외에 범위(지수, 표현 가능한 값의 폭)와 정밀도(가수, 값을 얼마나 세밀하게 표현하는지)로 비트를 나눠 쓴다. BF16과 FP16은 같은 16비트를 쓰지만, BF16은 범위에 더 많은 비트를(FP32와 같은 8비트 지수), 정밀도에는 더 적은 비트를 할당한다. 그래서 BF16은 FP16이 표현 못 하는 큰 값도 표현할 수 있지만(오버플로우로 무한대가 되지 않는다), 대신 정밀도는 FP16보다 떨어진다. 예를 들어 1234.56789는 FP16에서 1235.0(0.035% 변화), BF16에서 1232.0(0.208% 변화)이 된다.

잘못된 예 / 올바른 예 — 원문이 직접 든 사례다. 라마 2는 출시 당시 가중치가 BF16으로 지정됐다. 잘못된 예는 많은 팀이 이를 FP16으로 로드한 것이다 — BF16과 FP16은 같은 16비트라 언뜻 호환되어 보이지만 범위·정밀도 배분이 다르므로, 그 결과 모델 품질이 광고된 것보다 훨씬 떨어졌다. 올바른 예는 모델 카드나 공식 문서가 지정한 수치 형식을 그대로 지켜 로드하는 것이다. 이 혼란은 라마 3.1에서도 반복됐다.

원문이 완벽하지 않은 자리 — 이 절의 FP32→FP16/BF16/TF32 환산 예시표([표 7-3])는 추출 과정에서 열과 값이 뒤섞여 원문 그대로 옮기지 않는다. 본문이 문장으로 명시한 예시(1234.56789의 세 형식 변환값)만 위에 옮겼다.

양자화는 정밀도를 낮추는 것으로, 저렴하고 효과적이며 다양한 작업·아키텍처에 두루 적용된다. 100억 파라미터 모델을 32비트로 표현하면 가중치에 40GB가 필요하지만 16비트면 20GB로 충분하다. 무엇을 양자화할지는 성능 저하 없이 적용 가능한 부분을 신중히 골라야 하는데, 가중치 양자화가 활성화 양자화보다 더 안정적이고 정확도 손실이 적어 더 일반적이다. 언제 양자화할지는 두 갈래다.

• 학습 후 양자화(PTQ, Post-Training Quantization) — 모델이 완전히 학습된 뒤 양자화한다. 가장 널리 쓰이며, 모델을 직접 학습시키지 않는 애플리케이션 개발자에게 적합하다. 예를 들어 LLM.int8(Dettmers et al., 2022)은 LLM을 8비트로, QLoRA(Dettmers et al., 2023)는 4비트로 양자화했다.
• 양자화 인식 학습(QAT, Quantization-Aware Training) — 학습 중에 낮은 정밀도 동작을 시뮬레이션해, 추론 시 저정밀도에서도 품질이 좋은 모델을 만드는 것이 목표다. 다만 계산 자체는 여전히 높은 정밀도로 이뤄지므로 학습 시간이 줄지 않고, 오히려 시뮬레이션 부담으로 늘어날 수 있다.

정밀도를 낮추면 메모리뿐 아니라 계산 속도도 빨라지는 경우가 많다 — 더 큰 배치를 처리할 수 있고, 형식 자체의 연산이 빨라지기 때문이다(다만 형식 변환에 드는 추가 계산이 오히려 시간을 더 쓸 수도 있다). 반면 표현 범위를 벗어난 값은 무한대나 임의의 값으로 바뀔 수 있어 품질이 예상보다 떨어질 위험도 있다. 그래서 학습은 대개 일부 연산은 높은 정밀도(32비트), 나머지는 낮은 정밀도(16비트·8비트)로 처리하는 혼합 정밀도 방식을 쓴다.

이론상 1비트보다 더 작게 양자화할 수는 없다. 2024년 마이크로소프트 연구자들(Ma et al.)이 발표한 BitNet b1.58은 파라미터당 1.58비트만 쓰면서도, 원문 [표 7-4]를 재구성한 아래 결과처럼 39억 파라미터까지는 16비트 라마 2(라마 LLM으로 표기)와 비슷한 평균 성능을 보였다.

5. 파라미터 효율적 파인튜닝(PEFT)과 LoRA

5.1 전체 파인튜닝에서 PEFT로

파인튜닝 초기에는 모델이 충분히 작아 전체 파인튜닝(학습 가능한 파라미터 수 = 전체 파라미터 수)이 가능했다. 학습과 비슷해 보이지만, 학습은 무작위 초기화 가중치에서 시작하고 파인튜닝은 이미 학습된 가중치에서 시작한다는 차이가 있다. 앞 절의 계산처럼 70억 파라미터 모델을 FP16으로 전체 파인튜닝하면 가중치 14GB + 그래디언트·옵티마이저 스테이트 42GB = 56GB가 필요해 대부분의 소비자용 GPU 용량을 넘어선다(활성화 메모리는 별도).

이 때문에 파라미터의 일부만 업데이트하는 부분 파인튜닝이 등장했다(보통 출력에 가까운 레이어를 고르는데, 그 레이어들이 더 작업 특화적이기 때문이다). 하지만 홀스비 등의 연구(2019)에 따르면 BERT 대형 모델이 GLUE 벤치마크에서 전체 파인튜닝에 근접한 성능을 내려면 여전히 전체 파라미터의 약 25%를 업데이트해야 했다 — 부분 파인튜닝은 메모리는 줄이지만 파라미터 효율성은 떨어진다는 뜻이다.

PEFT(파라미터 효율적 파인튜닝)는 이 질문에서 나왔다 — 훨씬 적은 파라미터로도 전체 파인튜닝에 근접한 성능을 낼 수는 없을까? 명확한 기준은 없지만, 수십 배 적은 학습 가능한 파라미터로 전체 파인튜닝에 근접한다면 파라미터 효율적이라고 본다. 홀스비 등(2019)은 BERT의 각 트랜스포머 블록에 어댑터 모듈을 삽입해, 학습 가능한 파라미터의 단 3%만으로 전체 파인튜닝과 성능 차이 0.4% 이내를 달성했다(다만 어댑터가 추가 계산 단계를 만들어 추론 지연 시간이 늘어나는 단점이 있다). PEFT는 일반적으로 파라미터 효율적일 뿐 아니라 샘플 효율적이기도 하다 — 전체 파인튜닝이 수만~수백만 개 예시를 필요로 하는 반면, 일부 PEFT는 단 몇천 개로도 강력한 성능을 낼 수 있다.

PEFT는 크게 두 갈래로 나뉜다.

• 어댑터 기반 방법 — 모델 가중치에 추가 모듈(파라미터)을 붙이는 방식. 부가적 방법이라고도 한다. 대표가 LoRA(Hu et al., 2021)이며, BitFit(Zaken et al., 2021)·IA3(Liu et al., 2022, 다중 작업 파인튜닝에 유리)·LongLoRA(컨텍스트 길이 확장용 LoRA 변형) 등도 있다.
• 소프트 프롬프트 기반 방법 — 학습 가능한 연속 벡터(소프트 프롬프트)를 입력 토큰과 함께 주입해 모델 동작을 유도한다. 사람이 읽을 수 있고 고정된 하드 프롬프트와 달리, 소프트 프롬프트는 역전파로 최적화할 수 있다. 프리픽스 튜닝(Li and Liang, 2021)·P-튜닝(Liu et al., 2021)·프롬프트 튜닝(Lester et al., 2021)이 이름이 비슷해 혼동하기 쉬운데, 주된 차이는 소프트 프롬프트를 삽입하는 위치다(프리픽스 튜닝은 모든 트랜스포머 레이어 입력 앞, 프롬프트 튜닝은 임베딩된 입력 앞에만).

원문에 따르면 2024년 10월 기준 huggingface/peft 저장소의 공개 이슈 1,000개 이상을 분석한 결과 LoRA가 압도적으로 많이 쓰이고 있었고, 소프트 프롬프트는 상대적으로 덜 보편적이지만 프롬프트 엔지니어링보다 커스터마이징을 원하되 파인튜닝 투자는 꺼리는 사람들 사이에서 관심을 얻고 있었다.

5.2 LoRA — 원리·구성·서빙

작동 원리. LoRA(low rank adaptation)는 기존 어댑터 방식처럼 추론 지연 시간을 늘리지 않으면서 파라미터를 효율적으로 추가한다. n×m 차원의 가중치 행렬 W가 있을 때, LoRA는 ① 랭크 r을 정하고 두 개의 작은 행렬 A(r×m)와 B(n×r)를 구성한다. ② 두 행렬의 곱 B·A는 W와 같은 n×m 차원을 가지며, 이를 W에 더해 새 행렬 W' = W + B·A를 만들고 모델은 W 대신 W'을 쓴다(하이퍼파라미터 α로 B·A가 미치는 영향의 크기를 조절한다). ③ 파인튜닝 중에는 A와 B만 업데이트하고, W는 그대로 둔다.

참고 — 저랭크 분해란 — 9×9 행렬(81개 파라미터)을 9×1과 1×9 행렬의 곱(합쳐서 18개 파라미터)으로 근사하는 것과 같은 원리다. 원래 행렬을 완벽히 재현하지는 못해 정보 손실이 생기지만, 랭크(r)가 높을수록 원래 행렬의 정보를 더 많이 보존한다.

LoRA 논문은 GPT-3 실험에서 전체 파인튜닝의 단 0.0027%에 해당하는 약 470만 개 파라미터만으로도 여러 작업에서 전체 파인튜닝과 비슷하거나 더 나은 성능을 냈다고 보고했다. 이것이 가능한 이유로 유력하게 꼽히는 것이 LLM의 내재적 차원(intrinsic dimension)이 낮다는 발견이다(Li et al., 2018; Aghajanyan et al., 2020; Hu et al., 2021) — 사전 학습이 자연스럽게 모델의 내재적 차원을 압축하는 일종의 프레임워크 역할을 해서, 모델이 잘 학습될수록 적은 파라미터·적은 데이터로도 효과적으로 파인튜닝할 수 있게 된다는 것이다.

어디에 적용하고 랭크를 어떻게 정하나. LoRA는 개별 가중치 행렬 단위로 적용하며, 보통 어텐션 모듈의 쿼리(Wq)·키(Wk)·값(Wv)·출력 투영(Wo) 네 행렬에 적용한다. Hu 등(2021)은 GPT-3-175B를 학습 가능한 파라미터 1,800만 개(전체의 0.01%)로 제한했을 때, 어텐션 행렬 두 개만 고를 수 있다면 쿼리 행렬과 값 행렬의 조합이 일반적으로 가장 효과적이었고, 네 행렬 모두에 적용했을 때(행렬당 랭크 2) 가장 좋은 성능을 얻었다고 밝혔다. 실무 경험상 피드포워드 행렬까지 포함해 더 많은 가중치 행렬에 LoRA를 적용할수록 결과가 좋아지는 경향도 보고된다(데이터브릭스, Sooriyarachchi 2023).

원문이 완벽하지 않은 자리 — 어텐션 행렬별 랭크에 따른 WikiSQL·MultiNLI 성능을 담은 [표 7-5]는 추출 과정에서 가중치 유형·랭크·점수의 대응 관계가 뒤섞여, 어느 숫자가 어느 조합(Wq만/Wq+Wv/네 행렬 모두 등)에 해당하는지 신뢰 있게 되짚을 수 없었다. 표는 옮기지 않고, 본문이 명확히 진술한 결론(쿼리+값 조합이 좋다, 네 행렬 모두가 가장 좋다)만 남긴다.

랭크는 보통 4~64 정도의 작은 값이면 대부분의 활용 사례에 충분하며, 랭크를 늘려도 성능이 개선되지 않고 오히려 과적합으로 떨어질 수 있다는 관찰도 있다(다만 라쉬카(2023)는 자신의 작업에서 r=256일 때 최고 성능을 얻었다고 보고했다 — 최적값은 활용 사례마다 다르다는 뜻이다). α/r 비율은 실무에서 보통 1:8~8:1 사이로 설정한다.

서빙 — 병합할 것인가, 분리해 둘 것인가. LoRA로 파인튜닝한 모델을 서빙하는 방법은 두 가지다.

예를 들어 4096×4096 크기 원본 행렬 W(약 1,680만 파라미터)에 랭크 8 LoRA를 적용하면 A·B는 65,536개 파라미터다. 고객 100명에게 각각 LoRA로 파인튜닝한 모델을 서빙한다면, 병합 방식은 풀랭크 행렬을 100개 저장해야 해 총 16억 8천만 개(1,680만 × 100)가 필요하지만, 분리 방식은 풀랭크 행렬 1개 + 작은 행렬 100세트로 총 2,330만 개(1,680만 + 65,536 × 100)면 충분하다. 분리 방식은 고객을 바꿔 서빙할 때도 전체 가중치를 새로 로드할 필요 없이 LoRA 어댑터만 바꿔 끼우면 되므로 전환이 빠르다. 애플은 이 원리를 활용해 30억 파라미터 기본 모델 하나에 여러 LoRA 어댑터를 적용하고 양자화까지 더해, 아이폰의 여러 기능을 기기 안에서 처리하게 만들었다. 다만 LoRA의 가장 큰 단점은 전체 파인튜닝만큼 강력한 성능을 내지 못한다는 것이고, 모델 아키텍처에 대한 이해와 구현 기술이 더 필요해 전체 파인튜닝보다 어렵다는 점이다(다만 허깅페이스 PEFT·Axolotl·unsloth·LitGPT 같은 프레임워크가 인기 기본 모델에는 이미 지원을 마련해 두고 있다).

QLoRA — 양자화와 LoRA의 결합. [표 7-6]을 재구성하면, LoRA 어댑터가 쓰는 메모리는 모델 가중치 메모리에 비해 매우 작다.

즉 LoRA 자체의 파라미터 수를 더 줄여봤자 전체 메모리 절감 효과는 미미하다. 메모리를 더 아끼려면 모델 가중치·활성화·그래디언트를 양자화하는 편이 훨씬 효과적이며, 이를 구현한 것이 QLoRA(Dettmers et al., 2023)다. 기존 LoRA가 모델 가중치를 16비트로 유지한 채 파인튜닝했다면, QLoRA는 가중치를 정규 분포에 특화된 4비트 형식(NF4)으로 저장해 두었다가 순전파·역전파 계산 시에만 BF16으로 역양자화한다. 여기에 GPU 메모리가 부족할 때 CPU와 GPU 사이에 데이터를 자동으로 옮기는 페이징 옵티마이저까지 더해, 650억 파라미터 모델을 단일 48GB GPU에서 파인튜닝할 수 있게 했다.

QLoRA로 만든 과나코 모델 시리즈는 공개 벤치마크에서 좋은 성능을 보였다. [표 7-7]을 재구성하면 다음과 같다(2023년 5월, GPT-4가 심사한 Elo 점수).

과나코 65B가 GPT-4를 이기지는 못했지만 챗GPT보다 자주 선호됐다는 점이 QLoRA의 성과를 잘 보여준다. QLoRA의 한계는 NF4 양자화·역양자화를 오가는 계산 비용 때문에 학습 시간이 늘어날 수 있다는 점이며, QA-LoRA·ModuLoRA·IR-QLoRA 등 후속 연구가 이 한계를 계속 다루고 있다.

5.3 모델 병합

파인튜닝이 하나의 모델을 수정하는 방법이라면, 모델 병합은 여러 모델(특히 파인튜닝된 모델들)을 합쳐 맞춤형 모델을 만드는 방법이다. 파인튜닝을 보완하는 역할을 하며, 성능(서로 다른 강점을 가진 두 모델을 합쳐 각각보다 나은 단일 모델을 만듦)과 메모리 절감(여러 작업을 하나의 더 작은 모델로 통합) 양쪽에서 가치를 낸다.

모델 병합은 다중 작업 파인튜닝의 대안이기도 하다. 여러 작업을 한 모델에 담으려면 보통 ① 동시 파인튜닝(모든 작업 예시를 한 데이터셋에 담아 동시에 학습 — 더 많은 데이터·학습이 필요) ② 순차 파인튜닝(작업을 하나씩 순서대로 — 재앙적 망각에 취약해 새 작업을 배우며 이전 작업 성능이 크게 떨어질 수 있음) 중 하나를 택해야 했다. 모델 병합은 각 작업을 병렬로 따로 파인튜닝한 뒤 결과 모델들을 합치는 세 번째 길을 제공해, 각 작업에 특화된 성능을 유지하면서 재앙적 망각 문제도 줄인다. 스마트폰·스마트워치 같은 온디바이스 배포처럼 메모리가 빠듯한 환경에서 특히 빛을 발한다.

병합 방법은 파라미터를 결합하는 방식에 따라 세 갈래로 나뉜다.

합산의 대표는 선형 결합(가중 평균)과 구면 선형 보간법(SLERP)이다. 선형 결합은 두 모델 A, B의 가중치를 가중치 비율대로 평균 내는 것으로, 같은 기본 모델에서 파생된 모델끼리 결합할 때 가장 효과가 좋다. 이때 파인튜닝된 모델에서 기본 모델을 뺀 값을 작업 벡터라 부르는데, 작업 벡터끼리 더해 능력을 결합하거나 빼서 원치 않는 능력(편향·민감한 얼굴 인식 등)을 제거하는 작업 산술이 가능하다. SLERP는 두 벡터를 구 위의 점으로 보고 그 표면을 따라 최단 경로 위의 한 점을 병합 결과로 삼는 방법으로, 한 번에 두 벡터만 병합할 수 있어 세 개 이상이면 순차적으로 반복한다.

파인튜닝 중 조정된 파라미터 중 상당수는 실제로는 성능에 별 영향이 없는 불필요한 파라미터다. TIES(Yadav et al., 2023)·DARE(Yu et al., 2023) 같은 병합 기법은 작업 벡터를 합치기 전에 이런 파라미터를 먼저 가지치기해, 병합 모델의 품질을 크게 끌어올린다 — 병합할 모델이 많을수록 한 작업의 불필요한 파라미터가 다른 작업을 방해할 위험이 커지므로 가지치기가 더 중요해진다.

레이어 쌓기는 MoE(전문가 혼합) 모델을 만드는 데도 쓰인다 — 사전 학습된 모델의 특정 레이어를 여러 개 복사하고 라우터를 추가해 입력을 적합한 복사본으로 보낸 뒤, 병합된 모델과 라우터를 함께 추가 학습시키는 방식이다(Komatsuzaki et al., 2022). 투게더 AI는 이 방식으로 성능이 아쉬웠던 오픈 소스 모델 여섯 개를 조합해 에이전트 혼합(mixture-of-agents)을 만들었고, 2024년 발표 당시 일부 벤치마크에서 그 시점의 오픈AI GPT-4o와 필적하는 성능을 보였다(Wang et al., 2024) — 이는 그 시점의 실측 비교이며, GPT-4o는 이후 API에서 순차 은퇴한 과거 세대 모델이다(아래 「최신 동향」 참고).

참고 — 앙상블과의 차이 — 여러 모델을 합쳐 성능을 높이려는 시도는 모델 앙상블에서 출발했다. 모델 병합이 구성 모델의 파라미터를 섞어 하나로 만드는 것이라면, 앙상블은 구성 모델을 그대로 둔 채 출력만 결합한다(다수결 투표 등). 앙상블은 성능을 끌어올릴 수 있지만 요청마다 여러 번 추론해야 해 비용이 늘어난다. 원문은 이 흐름을 리더보드 순위 변화로도 짚는다 — 한때 모델 앙상블이 각종 리더보드 상위권을 휩쓸었듯, 이 절을 쓰던 시점에는 허깅페이스 오픈 LLM 리더보드 상위권에 병합 모델들이 즐비했다(아래 「최신 동향」 참고 — 그 리더보드는 이후 공식 은퇴했다).

5.4 파인튜닝 전술 — 프레임워크와 하이퍼파라미터

파인튜닝 자체를 결정하는 요소는 셋뿐이다 — 기본 모델, 파인튜닝 방법, 파인튜닝 프레임워크. 기본 모델 선택 기준(크기·라이선스·벤치마크 성능)은 4장에서 다룬 프롬프트 기반 방법과 공통이며, 예산 안에서 가장 좋은 모델로 시작해 그 모델도 요구사항을 못 채우면 더 약한 모델은 볼 것도 없다는 원칙이 유효하다. 오픈AI의 파인튜닝 모범 사례는 두 가지 개발 경로를 제시한다.

• 진행 경로 — ① 가장 저렴하고 빠른 모델로 파인튜닝 코드가 예상대로 동작하는지 테스트 ② 중간급 모델로 파인튜닝해 데이터 자체를 점검(데이터를 늘려도 학습 손실이 안 떨어지면 뭔가 잘못된 것) ③ 최고 성능 모델로 성능 상한을 탐색 ④ 좋은 결과가 나오면 비용 대비 성능을 비교해 활용 사례에 맞는 모델을 최종 선택.
• 증류 경로 — ① 작은 데이터셋과 감당할 수 있는 가장 강력한 모델로 최고 성능 모델을 만든다(기본 모델이 강력하므로 적은 데이터로 충분) ② 이 모델로 더 많은 학습 데이터를 생성한다 ③ 그 데이터로 더 저렴한 모델을 학습시킨다.

파인튜닝 방법은 데이터 양에 좌우된다. 전체 파인튜닝은 보통 최소 수천 개, 대개 훨씬 많은 예시가 필요한 반면 PEFT는 훨씬 적은 데이터로도 괜찮은 성능을 낸다 — 수백 개 정도의 작은 데이터셋이라면 전체 파인튜닝이 LoRA보다 나은 성능을 내지 못할 수도 있다. 파인튜닝된 모델을 몇 개나 어떻게 서빙할지도 고려해야 한다(§5.2의 병합/분리 서빙 비교).

파인튜닝 프레임워크는 편의성과 유연성의 트레이드오프다. 파인튜닝 API(모델 업체·클라우드 업체·서드파티 제공)는 데이터를 올리고 기본 모델만 고르면 되지만, 지원하는 기본 모델·노출된 설정이 제한적이다. LlaMA-Factory·unsloth·PEFT·Axolotl·LitGPT 같은 오픈 소스 프레임워크는 다양한 어댑터 기반 방법을 지원하고, 전체 파인튜닝을 원한다면 많은 기본 모델이 깃허브에 학습 코드를 공개해 두고 있다. 직접 파인튜닝하면 유연성은 커지지만 컴퓨팅 자원을 스스로 준비해야 하고, 여러 머신을 쓴다면 DeepSpeed·PyTorch Distributed·ColossalAI 같은 분산 학습 프레임워크가 필요하다.

자주 조정하는 하이퍼파라미터.

• 학습률 — 각 학습 단계에서 파라미터가 얼마나 빨리 바뀔지 정하는 보폭이다. 보통 1e-7~1e-3 사이에서 여러 값을 시도해야 하며, 사전 학습 마지막 학습률에 0.1~1 사이 값을 곱하는 방법이 흔히 쓰인다. 손실 곡선이 심하게 흔들리면 학습률이 너무 크고, 안정적인데 하락이 너무 느리면 너무 작은 것이다 — 손실 곡선이 안정적으로 유지되는 범위에서 가능한 한 높게 설정한다.
• 배치 크기 — 한 번의 가중치 업데이트에 쓰는 예시 수다. 너무 작으면(예: 8 미만) 학습이 불안정해질 수 있고, 클수록 안정적인 업데이트가 가능하지만 더 많은 메모리가 필요하다. 메모리가 부족해 작은 배치만 쓸 수 있다면, 여러 배치의 그래디언트를 모았다가 한꺼번에 업데이트하는 그래디언트 누적으로 안정성을 보완할 수 있다.
• 에폭 수 — 학습 데이터를 몇 바퀴 돌지 정한다. 수백만 개 예시가 있는 데이터셋은 1~2 에폭으로 충분할 수 있지만, 수천 개 규모는 4~10 에폭 이후에도 성능이 계속 개선될 수 있다. 학습 손실과 검증 손실이 함께 떨어지면 에폭을 늘려도 좋다는 신호이고, 검증 손실만 다시 오르기 시작하면 과적합이므로 에폭을 줄여야 한다.
• 프롬프트 손실 가중치 — 지시 파인튜닝에서 프롬프트와 응답 모두 손실에 영향을 줄 수 있는데, 실제 추론에서는 모델이 응답만 생성하므로 응답 쪽을 더 중요하게 학습해야 한다. 이 가중치가 100%면 프롬프트·응답을 동등하게, 0%면 응답에서만 학습한다. 일반적으로 기본값은 10% 안팎이다.

핵심 개념 정리

실무 체크리스트

• [ ] 오류의 원인이 정보 부족인지 행동 방식 문제인지 먼저 구분했는가?
• [ ] 프롬프트 엔지니어링과 예시 추가를 충분히 시도한 뒤에 파인튜닝을 검토했는가?
• [ ] 파인튜닝을 시작하기 전에 평가 기준과 평가 파이프라인부터 설계했는가?
• [ ] 학습 가능한 파라미터 수 × 옵티마이저 스테이트 개수로 필요한 메모리를 미리 계산해 봤는가?
• [ ] 모델이 공식으로 지정한 수치 형식(BF16/FP16 등)을 그대로 로드하고 있는가?
• [ ] 수백 개 규모의 작은 데이터셋인데 전체 파인튜닝을 고집하고 있지는 않은가?
• [ ] 여러 작업을 하나의 모델로 감당하기 어렵다면 LoRA 어댑터 분리 서빙이나 모델 병합을 검토했는가?
• [ ] 학습률·배치 크기를 하드웨어에 맞춰 실험했고, 손실 곡선으로 그 근거를 확인했는가?
• [ ] 파인튜닝된 모델을 계속 유지보수할 정책·예산을 세웠는가, 아니면 새 기본 모델로 교체할 기준을 정했는가?

연습문제

1. 판단. 사내 고객지원 챗봇이 고객 계정의 최신 주문 상태를 몰라서 자꾸 틀린 답을 내놓는다. RAG와 파인튜닝 중 무엇을 먼저 시도해야 하며, 그 근거는 무엇인가?
2. 계산. 70억(7B) 파라미터 모델을 FP16으로 로드하고 Adam 옵티마이저로 전체 파라미터를 파인튜닝하려 한다. 필요한 총 메모리(가중치 + 그래디언트 + 옵티마이저 스테이트, 활성화 메모리는 제외)를 계산하고, 24GB GPU 한 대로 충분한지 판단하라.
3. 설계. 같은 기본 모델에서 파생된 100개의 고객별 LoRA 어댑터를 서빙해야 한다. 어댑터를 원본 모델에 미리 병합하는 방식과 분리해서 유지하는 방식 중 무엇을 택해야 하며, 그 근거는 무엇인가?
4. 적용. 팀이 세 작업(제품 추천·주문 변경·일반 피드백)에 각각 다른 모델을 파인튜닝해 뒀는데, 스마트폰처럼 메모리가 제한된 기기에 세 모델을 모두 넣기엔 공간이 부족하다. 이 장에서 배운 어떤 기법으로 이 문제를 풀 수 있는가?

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-12, Tavily+Brave 웹검색 — SearXNG 는 두 질의 모두 무관 결과만 반환해 미반영) — 이 장이 설명하는 파인튜닝의 원리(전이 학습·PEFT·LoRA·모델 병합의 작동 방식)는 책 내용이 그대로 유효하다. 아래는 이 장이 이름을 들어 인용한 모델·리더보드 중 시간이 지나며 상태가 바뀐 것만 갱신 대상이다.

• 이 장이 벤치마크 비교의 역사적 사례로 인용한 GPT-4-0314·GPT-4o는 더 이상 현재 세대 모델이 아니다. GPT-4o는 2026-02-13 ChatGPT UI에서 물러났으며(OpenAI 공식 발표), API에서는 계속 제공되어 왔으나 개별 스냅숏(gpt-4o-2024-05-13)의 API 종료도 2026-10-23로 예고돼 있다(OpenAI Deprecations 공식 문서). 이 장의 벤치마크 비교(§2의 블룸버그GPT vs GPT-4-0314, §5.3의 에이전트 혼합 vs GPT-4o)는 둘 다 그 시점의 실측 결과를 보여주는 역사적 사례로서 여전히 유효하며, 이름을 현재 추천 모델로 읽지 않도록 주의가 필요하다.
• §5.3에서 언급한 허깅페이스 오픈 LLM 리더보드는 공식적으로 은퇴했다. 2년간 13,000개 이상의 모델을 평가한 뒤 종료됐고, 허깅페이스 허브에는 이를 대체하는 200개 이상의 커뮤니티 리더보드가 생겼다(Open LLM Leaderboard 은퇴 공지 — Hugging Face 공식). 지금 모델을 비교하려면 이 장이 예로 든 단일 리더보드 대신, 과제에 맞는 커뮤니티 리더보드를 골라야 한다.
• PEFT 프레임워크(허깅페이스 PEFT·unsloth·Axolotl·LitGPT)는 이 장이 쓰인 시점과 마찬가지로 계속 활발히 관리되고 있다. huggingface/peft 저장소와 unsloth 저장소 모두 최근까지 커밋이 이어지는 활성 프로젝트다.

부록 A. 핵심 비교표

파인튜닝 vs RAG — 오류 원인 기준

전체 파인튜닝 vs PEFT(LoRA)

학습 후 양자화(PTQ) vs 양자화 인식 학습(QAT)

모델 병합 세 가지 방식

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식·원논문, 생존 확인 2026-09-12)

• LoRA 원논문 — §5.2의 저랭크 분해·랭크 r·어텐션 행렬 적용 근거. LoRA: Low-Rank Adaptation of Large Language Models (Hu et al., 2021)
• QLoRA 원논문 — §5.2의 NF4 양자화·페이징 옵티마이저 구현 세부. QLoRA: Efficient Finetuning of Quantized LLMs (Dettmers et al., 2023)
• Fine-Tuning or Retrieval? — §3의 RAG vs 파인튜닝 비교 실험 원논문. Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs (Ovadia et al., 2024)
• BitNet b1.58 원논문 — §4.2의 1.58비트 극단 양자화 사례 출처. The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits (Ma et al., 2024)
• 허깅페이스 PEFT 공식 문서 — §5.1·§5.2가 다루는 PEFT 기법들의 실제 구현체. PEFT — Hugging Face 공식 문서 · 공식 저장소
• EleutherAI "Transformer Math 101" — §4.1의 메모리 계산 공식을 학습·분산 환경까지 확장한 참고 자료. Transformer Math 101 — EleutherAI 공식 블로그

더 해보기 — 읽고 끝내지 않으려면

• §4.1의 공식(N × M, Adam 3배수)으로 지금 쓰고 있는(또는 써 보고 싶은) 모델의 추론·학습 메모리를 직접 계산해 보고, 실제 GPU 사양과 비교해 본다.
• §5.2의 LoRA 서빙 비교표를 참고해, 자신의 프로젝트가 "서빙할 LoRA 모델이 하나"인지 "멀티 LoRA"인지 먼저 정하고 그에 맞는 서빙 방식을 골라 본다.

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (RAG 우선 판단) 고객 계정의 최신 주문 상태를 모르는 것은 전형적인 "정보 부족 오류"다(모델이 애초에 그 비공개·최신 정보를 가지고 있지 않은 경우). §3의 판단 기준대로 이런 오류는 파인튜닝으로 고칠 수 없다 — 아무리 학습시켜도 실시간으로 바뀌는 주문 데이터를 모델 가중치에 담을 수는 없기 때문이다. 관련 정보 소스(주문 시스템 API·DB)에 접근하게 해주는 RAG가 정답이며, 키워드 기반 검색처럼 단순한 방법부터 시작해 보는 것이 좋다.

2. (메모리 계산) 가중치: 70억 × 2바이트 = 14GB. Adam 옵티마이저로 전체 파라미터를 파인튜닝하면 학습 가능한 파라미터마다 그래디언트 1개 + 옵티마이저 스테이트 2개, 총 3개 값이 필요하므로 70억 × 3 × 2바이트 = 42GB. 총합은 14GB + 42GB = 56GB로, 활성화 메모리를 제외하고도 이미 24GB GPU 한 대의 두 배가 넘어 부족하다. LoRA 같은 PEFT로 학습 가능한 파라미터 수를 줄이거나, 양자화로 파라미터당 메모리(M)를 줄이는 방법을 함께 검토해야 한다.

3. (LoRA 서빙 방식 선택) 100명의 고객에게 각각 다른 LoRA 어댑터를 서빙해야 하므로 "분리 유지" 방식이 맞다. 병합 방식은 고객마다 풀랭크 행렬 W'를 통째로 저장해야 해 저장 공간이 고객 수만큼 그대로 곱해지지만(예시 계산에서 16억 8천만 개), 분리 방식은 풀랭크 행렬 W 하나와 작은 (A, B) 세트 100개만 저장하면 되고(예시 계산에서 2,330만 개) 고객을 바꿔 서빙할 때도 어댑터만 교체하면 된다. 대신 추론 시 A·B를 W에 매번 합쳐야 해 지연 시간이 조금 늘어난다는 점은 감수해야 한다.

4. (모델 병합 적용) §5.3의 모델 병합을 쓰면 된다. 세 작업에 각각 파인튜닝한 모델을 별도로 기기에 넣는 대신, 세 모델(또는 그 LoRA 어댑터)을 하나로 병합해 메모리는 훨씬 적게 쓰면서 여러 작업을 처리하는 단일 모델로 만들 수 있다. 특히 어댑터 기반 모델이라면 각 어댑터를 합산 방식으로 결합하는 것이 효과적이며, 이는 온디바이스 배포에서 모델 병합이 가장 빛을 발하는 대표적인 상황이다.